Mythas Rothron
Federal Navy Academy
Gallente Federation
0
   |
Posted - 2012.04.02 22:57:00 -
[2] - Quote
Katrina Bekers wrote:
I know who said that.
And I confirm every word.
Which is to say that a bunch of individual developers are as supportive as it gets to help us linux nerds keep playing. But it also means that there is not any official nor "best effort" support from the company, which is who ultimately pays for the worktime development efforts.
We have many individuals to thank for their freetime support. But pressuring the company itself is not going anywhere.
Im my car analogy, one can't complain at the manufacturer. But may very well adapt the injectors to treat the home brewn concotion as fuel, and mix it to a point where the car actually runs on wine.
This.
I'm seeing all of these people who use a free/libre operating system designed to be tweaked, customized, and whatnot, and they contribute little to nothing back to the FOSS community, and they demand that a company already struggling to make it in this economy completely rewrite their main product to run on a platform that makes up only 2% of the entire desktop market.
The developers LOVE the linux OS, they have no problem tweaking their systems to get their game running on it, and they accept that their management team isn't going to pay them to build an OpenGL client.
The comments about Python are irrelevant, they contribute code and money upstream so they do more for those OSS projects than their users do.
I am a software developer. I write code for the Android Open Source Project, apps on that platform, and the linux kernel itself for the Arch project. I use a linux distro in 95% of my work, and I still totally agree with the decision not to build a native linux client. It doesn't make fiscal sense.
Also, the wine configuration is not that hard to follow, and the latest link
http://appdb.winehq.org/objectManager.php?sClass=version&iId=25544
describes which specific configurations. And google can source the rest.
What we need, is for people to contribute to some sort of project to make pulling in the libraries needed and whatnot much easier, since it seems most of the people here are sick of struggling with that. Possibly create a PlayOnLinux script?
****This is the end of the relevance of the post****
Whitehound wrote:Still, it is irrelevant. Take all your software development knowledge and throw it away, because strictly speaking are 32bit Windows binaries when run under 64bit Windows not native either and need support to run in a 64bit environment. 32bit Windows binaries run native under Linux with WINE, because WINE Is Not an Emulator. You could go as far as saying that any software that is not a 64bit C/C++ application, which directly interfaces with the operating system and hardware, are not native applications on either Linux or Windows. Some of EVE's code was compiled with GCC some with M$V8. Why draw a line?! Even the shader code needs to be compiled by DirectX and OpenGL before it can run on the GPU. You are trying to draw a line somewhere, which serves no purpose. Your argument is pointless in this discussion, because it is not about what you see as native and lack to understand, but what gets support through CCP!
Hmm...this is right and wrong.
1) 32 bit binaries in x64 windows--this statement was completely wrong. x64 Windows does not emulate the cpu instruction set for a 32-bit processor; today's cpu's can run either code set natively, translated at the binary level. I think you're referring to the multiarch libraries, that allow the 32-bit applications to be run "natively" on a 64 bit machine.
2) Wine Is Not an Emulator--this means it's not like dosbox, translating code build for a different architecture entirely (ie an N64). Wine is an implementation of a libraries interpretation layer that, for all intents and purposes, allows Windows libraries and binaries to function on a Linux/BSD system.
3) A native application is merely an application that is compiled against/uses binary libraries on the system. So, my C++ hello world application will compile on a Windows machine using VS2010 and a linux machine with GCC, but won't function on the other system due to byte-level incompatibility (and I'll spare you the kernel explanation here).
4) Eve's game code was not compiled with GCC. It is compiled with a Microsoft compiler, and the python pieces are not compiled (it's an interpreted, or "emulated" language).
5) DX libraries are binary-compatible with Windows NT-based systems only. Nebu Retski is right, the source code of EVE O cannot be compiled on a linux distribution because it compiles against the DirectX libraries among several other pieces from the API, which aren't compiled on linux. His statement about Cedega is almost correct--Cedega just tells Wine to translate the function calls meant for the NT kernel to a format readable by the linux kernel.
So, Whitehound, your post was kind of irrelevant until the last line. Whitehound wrote:because it is not about what you see as native and lack to understand, but what gets support through CCP!
^^ this exactly. And CCP's management will not allow the developers to make a binary-compatible client for the Linux platform. |